Skip to content

Conversation

davidgovea
Copy link

Fixes #4

First off -- thank you for this plugin! What a game changer! Has been working out great.

This PR fixes a small logic bug that required :build_type to always be the first option.

While iterating through the |k,v| entries of options, the intent was to only operate on :build_type.
Previously, the check was next if not options.key?(Pod::UserOption.keyword) ("does :build_type exist?")
This would be true even if k was not :build_type, causing the wrong key to be operated on (unless build_type was first)

This PR changes the check to next if k != Pod::UserOption.keyword, and I have verified that this results in the intended behavior.
However, I'm not totally sure how to implement tests of this behavior -- I don't work in ruby very often. Happy to help with that if you have any guidance, though!

Thank you for reviewing!

@mlch911
Copy link

mlch911 commented Jul 6, 2023

Can this be merged ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Invalid 'Podfile' could not parse a build_type
2 participants